In a network function virtualization (NFV) scenario, architectures of a conventional network and network node change greatly. In a new network architecture, a conventional physical telecommunications node evolves to be a virtual node on a virtualizer, and exists in a form of a virtual machine. In this way, multiple conventional physical nodes are deployed on a same physical host machine, share hardware resources, and even share resources with other third-party application software. In addition, for the convenience of dynamic migration of a virtual machine and enhancement of performance of communication between virtual machines on a same virtualizer, a conventional IP network evolves to be a virtual network by using a virtual switch and a virtual network adapter, and the virtual machines directly communicate with each other by using the virtual network, bypassing a conventional physical network device. However, communication between virtual machines inside the virtual network and communication between a virtual machine and an external network are faced with security risks, for example, mutual attacks between virtual machines, attacks by a host machine application against a host and a virtual machine, an attack by a host machine by using network intercommunication with a virtual machine network, an attack against a virtual machine by using a remote maintenance and management channel, an attack against an external network by using a network edge node, and the like. Therefore, with these communication threats facing network function virtualization, a secure connection needs to be established by using a particular security technology in virtualized communication, so as to ensure confidentiality and integrity of the virtualized communication. To establish a secure connection, X.509-based certificates need to be configured for both entities involved in virtualized communication.
A virtualized network function entity is not a conventional hardware entity, but is generated as required in a software manner and dynamically exists. In addition, an installation location of the virtualized network function entity is not fixed. Therefore, a conventional entity certificate configuration method is not applicable to the network function virtualization scenario. Further, multiple instances may coexist for one virtualized network function entity, and if a conventional entity certificate configuration method, in which certificate configuration is performed by a provider of the virtualized network function entity, is used, a same certificate is installed for multiple instances due to a same installation package of the virtualized network function entity, thereby causing a relatively severe security risk.